Organizational population health management platform and programs

ABSTRACT

Methods, systems, and computer-readable media are provided for organizational management of population health. A network management service builds and maintains data stores of organizational data associated with one or more healthcare organizations. A population health management service receives raw data from disparate sources, creates a reference record for each raw data source, and generates patient-centric longitudinal population records using the reference records. Programs for managing population health utilize both the organizational data and the population records to generate condition-specific or objective-specific solutions.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application, having attorney docket number CRNI.176025, andentitled “Organizational Population Health Management Platform andPrograms,” claims priority to U.S. Provisional Application No.61/710,877, filed Oct. 8, 2012, and entitled “Organizational Managementof Population Health.” The entirety of the aforementioned application isincorporated by reference herein.

This application, having attorney docket number CRNI.176025, andentitled “Organizational Population Health Management Platform andPrograms,” is related by subject matter to concurrently filed U.S.patent application Ser. No. ______, having attorney docket numberCRNI.196078, entitled “Provider and Patient Attribution Programs;” U.S.patent application Ser. No. ______, having attorney docket numberCRNI.196079, entitled “Contracts and Organization Management Program;”U.S. patent application Ser. No. ______, having attorney docket numberCRNI.196080, entitled “Outreach Program;” and U.S. patent applicationSer. No. ______, having attorney docket number CRNI.196093, entitled“Score Cards.” The entireties of the aforementioned applications areincorporated by reference herein.

BRIEF SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

In brief and at a high level, this disclosure describes, among otherthings, methods, systems, computer storage media, and graphical userinterfaces for organizational management of population health. A systemor platform for managing population health includes a network managementservice that builds, maintains, and updates data stores that includeinformation about healthcare organizations, healthcare providers, andinformation concerning contractual provisions between healthcareorganizations and payers (e.g., insurance companies). The networkmanagement service also includes a program builder that buildscondition-specific and/or objective-specific program templates. Theprogram templates are designed to, among other things, identifypopulation segments based on condition or purpose, stratify thepopulation segment using different factors, generate workflows,attribute patients within the segment to healthcare providers, managehealthcare organizations and contracts, measure intervention outcomes,and the like.

The system further includes a population management service that builds,maintains, and updates data stores that include longitudinalpatent-centric information drawn from a variety of disparate datasources. Such information may include demographic information, claimsinformation, pharmacy information, clinical care information,socioeconomic information, financial information, and the like.Additionally, the system includes a compiler that extracts a programtemplate and customizes or localizes it based on a particular healthcareorganization's organizational and provider information as well as theparticular contractual provisions associated with the healthcareorganization and its associated payers.

At run-time, a program engine in the system uses the customized programtemplates and the patient population information from the populationmanagement service to generate condition-specific or objective-specificpatient population data for the healthcare organization. This data isused by the healthcare organization to, among other things, identifypatient segments based on a condition or for a specific purpose,stratify patients within the segment by degree of risk, generateinterventions, attribute patients in the segment to healthcare providersassociated with the particular healthcare organization, measureintervention outcomes, manage payer/organization contracts, determineprovider incentives, and the like.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are described in detail below with reference to the attacheddrawing figures, wherein:

FIG. 1 is a block diagram of an exemplary computing environment suitableto implement embodiments of the present invention;

FIG. 2 is a block diagram of an exemplary system for managing populationhealth suitable to implement embodiments of the present invention;

FIGS. 3-4 are flow diagrams illustrating exemplary methods of managingpopulation health at a healthcare organization level in accordance withembodiments of the present invention;

FIG. 5 is an exemplary graphical user interface suitable to build acondition-specific or objective-specifc program template in accordancewith an embodiment of the present invention;

FIG. 6 is an exemplary graphical user interface suitable to generate apredictive model of population health data for a healthcare organizationin accordance with an embodiment of the present invention;

FIG. 7 is a schematic illustration of relationships between raw datasources, reference records, and population records in accordance with anembodiment of the present invention;

FIG. 8 is a flow diagram of an exemplary method of attributing patientsto one or more providers in accordance with an embodiment of the presentinvention;

FIG. 9 is a flow diagram of an exemplary method of modifying anattribution scheme based on updated organizational or patient data inaccordance with an embodiment of the present invention;

FIG. 10 is a flow diagram of an exemplary method of attributing patientsto scorable patient groups in accordance with an embodiment of thepresent invention;

FIG. 11 is a flow diagram of an exemplary method of a healthcareorganization managing contracts in accordance with an embodiment of thepresent invention;

FIG. 12 is an exemplary graphical user interface for presenting datarelated to current contract performance in accordance with an embodimentof the present invention;

FIG. 13 is an exemplary graphical user interface for presenting currentpatient utilization by provider type and recommendations for improvingcurrent patient utilization by provider type in accordance with anembodiment of the present invention;

FIG. 14 is an exemplary user interface for presenting projected outcomesfor a healthcare organization upon selection of generated venue-shiftingrecommendations in accordance with an embodiment of the presentinvention;

FIG. 15 is a flow diagram of an exemplary method of intra-organizationoutreach in accordance with an embodiment of the present invention;

FIG. 16 is a flow diagram of an exemplary method of generating outreachevents for an identified patient population segment in accordance withan embodiment of the present invention;

FIGS. 17-23 depict exemplary user interfaces for building score plansfor a healthcare organization, a provider, a payer, and a patient inaccordance with embodiments of the present invention;

FIGS. 24-25 depict exemplary provider score plan user interfaces forenabling providers to track progress towards reaching a scoring goal inaccordance with embodiments of the present invention; and

FIG. 26 depicts an exemplary score plan user interface used by ahealthcare organization to track a provider group's progress towardreaching a scoring goal in accordance with embodiments of the presentinvention.

DETAILED DESCRIPTION

The subject matter of the present invention is described withspecificity herein to meet statutory requirements. However, thedescription itself is not intended to limit the scope of this patent.Rather, the inventors have contemplated that the claimed subject mattermight also be embodied in other ways, to include different steps orcombinations of steps similar to the ones described in this document, inconjunction with other present or future technologies. Moreover,although the terms “step” and/or “block” may be used herein to connotedifferent elements of methods employed, the terms should not beinterpreted as implying any particular order among or between varioussteps herein disclosed unless and except when the order of individualsteps is explicitly described.

In brief and at a high level, this disclosure describes, among otherthings, methods, systems, computer storage media, and graphical userinterfaces for organizational management of population health. A systemor platform for managing population health includes a network managementservice that builds, maintains, and updates data stores that includeinformation about healthcare organizations, healthcare providers, andinformation concerning contractual provisions between healthcareorganizations and payers (e.g., insurance companies). The networkmanagement service also includes a program builder that buildscondition-specific and/or objective-specific program templates. Theprogram templates are designed to, among other things, identifypopulation segments based on condition or purpose, stratify thepopulation segment using different factors, generate workflows,attribute patients within the segment to healthcare providers, manageorganization and contracts, generate outreach events, measureintervention outcomes, and the like.

The system further includes a population management service that builds,maintains, and updates data stores that include longitudinalpatent-centric information drawn from a variety of disparate datasources. Such information may include demographic information, financialinformation, socioeconomic information, claims information, pharmacyinformation, clinical care information, and the like. Additionally, thesystem includes a compiler that extracts a program template andcustomizes or localizes it based on a particular healthcareorganization's organizational and provider information as well as theparticular contractual provisions associated with the healthcareorganization and its associated payers.

At run-time, a program engine in the system uses the customized programtemplates and the patient population information from the populationmanagement service to generate condition-specific or objective-specificpatient population data for the healthcare organization. This data isused by the healthcare organization to, among other things, identifypatient segments based on a condition or for a specific purpose,stratify patients within the segment by degree of risk, generateinterventions, attribute patients in the segment to healthcare providersassociated with the particular healthcare organization, measureintervention outcomes, manage payer/organization contracts, determineprovider incentives, generate outreach events, and the like.

An exemplary computing environment suitable for use in implementingembodiments of the present invention is described below. FIG. 1 is anexemplary computing environment (e.g., medical-informationcomputing-system environment) with which embodiments of the presentinvention may be implemented. The computing environment is illustratedand designated generally as reference numeral 100. The computingenvironment 100 is merely an example of one suitable computingenvironment and is not intended to suggest any limitation as to thescope of use or functionality of the invention. Neither should thecomputing environment 100 be interpreted as having any dependency orrequirement relating to any single component or combination ofcomponents illustrated therein.

The present invention might be operational with numerous other purposecomputing system environments or configurations. Examples of well-knowncomputing systems, environments, and/or configurations that might besuitable for use with the present invention include personal computers,server computers, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of theabove-mentioned systems or devices, and the like.

The present invention might be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Exemplary program modules comprise routines,programs, objects, components, and data structures that performparticular tasks or implement particular abstract data types. Thepresent invention might be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules might be located in association with localand/or remote computer storage media (e.g., memory storage devices).

With continued reference to FIG. 1, the computing environment 100comprises a computing device in the form of a control server 102.Exemplary components of the control server 102 comprise a processingunit, internal system memory, and a suitable system bus for couplingvarious system components, including data store 104, with the controlserver 102. The system bus might be any of several types of busstructures, including a memory bus or memory controller, a peripheralbus, and a local bus, using any of a variety of bus architectures.Exemplary architectures comprise Industry Standard Architecture (ISA)bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus,Video Electronic Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus, also known as Mezzanine bus.

The control server 102 typically includes therein, or has access to, avariety of non-transitory computer-readable media. Computer-readablemedia can be any available media that might be accessed by controlserver 102, and includes volatile and nonvolatile media, as well as,removable and nonremovable media. By way of example, and not limitation,computer-readable media may comprise computer storage media andcommunication media. Computer storage media includes both volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canbe accessed by control server 102. Communication media typicallyembodies computer-readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer-readable media.

The control server 102 might operate in a computer network 106 usinglogical connections to one or more remote computers 108. Remotecomputers 108 might be located at a variety of locations in a medical orresearch environment, including clinical laboratories (e.g., moleculardiagnostic laboratories), hospitals and other inpatient settings,veterinary environments, ambulatory settings, medical billing andfinancial offices, hospital administration settings, home healthcareenvironments, and clinicians' offices. Clinicians or healthcareproviders may comprise a treating physician or physicians; specialistssuch as surgeons, radiologists, cardiologists, and oncologists;emergency medical technicians; physicians' assistants; nursepractitioners; health coaches; nurses; nurses' aides; pharmacists;dieticians; microbiologists; laboratory experts; laboratorytechnologists; genetic counselors; researchers; veterinarians; students;and the like. The remote computers 108 might also be physically locatedin nontraditional medical care environments so that the entirehealthcare community might be capable of integration on the network. Theremote computers 108 might be personal computers, servers, routers,network PCs, peer devices, other common network nodes, or the like andmight comprise some or all of the elements described above in relationto the control server 102. The devices can be personal digitalassistants or other like devices.

Computer networks 106 comprise local area networks (LANs) and/or widearea networks (WANs). Such networking environments are commonplace inoffices, enterprise-wide computer networks, intranets, and the Internet.When utilized in a WAN networking environment, the control server 102might comprise a modem or other means for establishing communicationsover the WAN, such as the Internet. In a networking environment, programmodules or portions thereof might be stored in association with thecontrol server 102, the data store 104, or any of the remote computers108. For example, various application programs may reside on the memoryassociated with any one or more of the remote computers 108. It will beappreciated by those of ordinary skill in the art that the networkconnections shown are exemplary and other means of establishing acommunications link between the computers (e.g., control server 102 andremote computers 108) might be utilized.

In operation, an organization might enter commands and information intothe control server 102 or convey the commands and information to thecontrol server 102 via one or more of the remote computers 108 throughinput devices, such as a keyboard, a pointing device (commonly referredto as a mouse), a trackball, or a touch pad. Other input devicescomprise microphones, satellite dishes, scanners, or the like. Commandsand information might also be sent directly from a remote healthcaredevice to the control server 102. In addition to a monitor, the controlserver 102 and/or remote computers 108 might comprise other peripheraloutput devices, such as speakers and a printer.

Although many other internal components of the control server 102 andthe remote computers 108 are not shown, such components and theirinterconnection are well known. Accordingly, additional detailsconcerning the internal construction of the control server 102 and theremote computers 108 are not further disclosed herein.

Turning now to FIG. 2, an exemplary population health management system200 is depicted suitable for use in implementing embodiments of thepresent invention. The population health management system 200 is merelyan example of one suitable computing system environment and is notintended to suggest any limitation as to the scope of use orfunctionality of embodiments of the present invention. Neither shouldthe population health management system 200 be interpreted as having anydependency or requirement related to any single module/service/componentor combination of modules/services/components illustrated therein.

The population health management system 200 includes a networkmanagement service 210, a population management service 212, a programengine 214 and a compiler 236 all in communication with each otherthrough wired connections or through a network. The network may include,without limitation, one or more local area networks (LANs) and/or widearea networks (WANs). Such networking environments are commonplace inoffices, enterprise-wide computer networks, intranets and the Internet.Accordingly, the network is not further described herein.

The network management service 210, the population management service212, the program engine 214 and the compiler 236 are merely exemplary.While each of these components/services/modules is illustrated as asingle unit, it will be appreciated that each of thesecomponents/services/modules is scalable. For example, the networkmanagement service 210 may in actuality include a plurality of computingdevices in communication with one another. Components of the networkmanagement service 210, the population management service 212, theprogram engine 214 and the compiler 236 may include a processing unit,internal system memory, and a suitable system bus for coupling varioussystem components, including one or more data stores for storinginformation (e.g., files and metadata associated therewith). Each ofthese components/services/modules typically includes, or has access to,a variety of computer-readable media.

In some embodiments, one or more of the illustratedcomponents/services/modules may be implemented as stand-aloneapplications. In other embodiments, one or more of the illustratedcomponents/services/modules may be integrated directly into theoperating system of the population health management system 200. Thecomponent/services/modules illustrated in FIG. 2 are exemplary in natureand in number and should not be construed as limiting. Any number ofcomponents/services/modules may be employed to achieve the desiredfunctionality within the scope of embodiments hereof. Further,component/services/modules may be located on any number of servers. Byway of example only, the population health management system 200 mightreside on a server, cluster of servers, or a computing device remotefrom one or more of the remaining components.

It should be understood that this and other arrangements describedherein are set forth only as examples. Other arrangements and elements(e.g., machines, interfaces, functions, orders, and groupings offunctions, etc.) can be used in addition to or instead of those shown,and some elements may be omitted altogether. Further, many of theelements described herein are functional entities that may beimplemented as discrete or distributed components or in conjunction withother components/modules, and in any suitable combination and location.Various functions described herein as being performed by one or moreentities may be carried out by hardware, firmware, and/or software. Forinstance, various functions may be carried out by a processor executinginstructions stored in memory.

As shown in FIG. 2, the network management service 210 includes areceiving component 216, a data store builder 218, a program buildercomponent 220 and various data stores 222, 224, and 226. The populationmanagement service 212 includes a receiving component 228, a data storebuilder 230, a matching component 232, and a population data store 234.In some embodiments, one or more of the components 216, 218, 220, 228,230, and 232 may be implemented as stand-alone applications. In otherembodiments, one or more of the components 216, 218, 220, 228, 230, and232 may be integrated directly into the operating system of a computingdevice such as the remote computer 108 of FIG. 1. It will be understoodthat the components 216, 218, 220, 228, 230, and 232 illustrated in FIG.2 are exemplary in nature and in number and should not be construed aslimiting. Any number of components may be employed to achieve thedesired functionality within the scope of embodiments hereof.

The data stores 222, 224, 226, and 234 are configured to storeinformation used by network management service 210 and the populationmanagement service 212. The content and volume of such information inthe data stores 222, 224, 226, and 234 are not intended to limit thescope of embodiments of the present invention in any way. Further,although each data store 222, 224, 226, and 234 is illustrated as asingle, independent component, the data stores 222, 224, 226, and 234may, in fact, be a plurality of storage devices, for instance, adatabase cluster, portions of which may reside on the network managementservice 210, the population management service 212, the program engine214, and/or any combination thereof.

Turning first to the network management service 210, the receivingcomponent 216 is configured to receive organizational data from one ormore healthcare organizations. The healthcare organizations may bearsome logical relationship to each other, or, alternatively, thehealthcare organizations may be disparate with no logical relationshipto one another. As used throughout this application, a healthcareorganization may comprise a single healthcare facility with anassociated group of healthcare providers such as physicians,pharmacists, nurses, health coaches, therapists, and the like. Ahealthcare organization may also comprise a network of healthcarefacilities, each healthcare facility having an associated group ofhealthcare providers. The healthcare organization may create suchnetworks in order to achieve certain financial and/or clinicalobjectives. The healthcare facilities may be located geographicallyclose to one another or may be spread across a large geographical area.Further, the healthcare facilities may comprise a network of hospitals,clinics, provider offices, nursing homes, pharmacies, home healthservices, and the like. As such, the term “healthcare organization” asused herein is meant to be construed broadly to cover a wide range ofhealthcare scenarios.

The organizational data may include data about each healthcare facilitysuch as operating hours, type of care provided, unique characteristicsassociated with the health care facility, geographic location,accessibility, associated providers, and the like. The organizationaldata may also include healthcare provider data such as names,credentials, affiliations, areas of practice, geographic location,provider preferences, current patient load, demographic characteristicssuch as gender or age, provider outcome data, and the like.

Continuing, the organizational data may also include contractual data.By way of background, when a healthcare organization enters into apayment agreement with a payer, a contract is generated that includes avariety of information or provisions. A payer refers to an entity thatintends to pay or is responsible for payment of healthcare services.Payers include without limitation employers, government entities (suchas Centers for Medicare and Medicaid Services), charities, patients,insurers and secondary insurers. The contract between a payer and ahealthcare organization may include financial objectives (e.g., paymentterms), clinical objectives, warranties, terms and conditions, and thelike. For example, a payer may agree to pay a healthcare organization acertain amount if the healthcare organization meets certain qualitymeasures or clinical objectives (e.g., a fee-sharing arrangement). Thequality measures may include keeping readmission rates below a certainlevel, keeping costs of care low, meeting standards-of-care for certaindisease conditions, and the like. As used in this application, the term“organizational data” is meant to be construed broadly to cover a widerange of information regarding healthcare organizations, healthcareproviders, and contractual or agreement terms.

The data store builder 218 is configured to build, maintain, and updatethe data stores 222, 224, and 226 using information received by thereceiving component 216. The contract data store 222 stores contractualinformation between one or more healthcare organizations and theirassociated payers; the contractual information, as mentioned, includesclinical objectives as well as financial objectives. The organizationdirectory data store 224 stores organizational information pertaining toone or more healthcare organizations, and the provider directory datastore 226 stores healthcare provider information. The information storedin the data stores 222, 224, and 226 may arise from disparateorganizations or sources that bear no relationship to each other. Thedata stores 222, 224, and 226 may be networked storage or distributedstorage including storage on servers located in the cloud. Thus, it iscontemplated that for some embodiments, the information stored in thedata stores 222, 224, and 226 is not stored in the same physicallocation. As new organizational information is received by the receivingcomponent 216, the data store builder 218 updates the existing datastores 222, 224, and/or 226.

The program builder component 220 is configured to, in one aspect,automatically build one or more condition-specific or objective-specificprogram templates to be used by, for example, a healthcare organizationto manage the health of a population segment or to achieve one or moreobjectives. In another aspect, a user, such as a programmer associatedwith a healthcare organization, can use the program builder component220 to build a condition-specific or objective-specific program templatethat is customized to the particular healthcare organization. In generalterms, a condition-specific or objective-specific program template maybe defined as a systematic approach to identify, predict, and/or managean objective or condition at a population, provider, or patient level.The program builder component 220 may have access to knowledgerepositories that include algorithms, outcome-related goals, referencematerials, standards-of-care, recommendation protocols, and the like.This information may be specific to a healthcare organization orfacility, or the information may be promulgated by, for example,nationally-recognized medical organizations or governing bodies and beapplicable to multiple different healthcare organizations.

As mentioned, in one aspect, the program templates may be conditionspecific and designed to better help healthcare organizations manage,for example, a population segment with a certain disease condition. Thenumber and type of conditions are numerous and examples includewellness, heart disease, pre-diabetes, diabetes, stroke, and the like.The program templates are configured, in one aspect, to identifypatients within a population segment who have a defined condition orhave risk factors that may lead to the development of the condition. Theprogram templates are also configured to stratify patients within theidentified segment by degree of severity or risk or by disease type, andto generate interventions or action workflows designed to reduce diseaseseverity or risk and to improve outcome. Additional uses for thecondition-specific program templates are to measure outcomes related totreatment interventions, predict outcomes based on the implementation ofa proposed action, and also to attribute patients within the identifiedsegment to appropriate care providers (e.g., primary care physicians,health coaches, specialists such as endocrinologists, podiatrists, andthe like) best suited to treat the condition in a cost-effective manner.

Program templates may also be objective-specific and designed to assista healthcare organization reach a defined objective. Objective-specifictemplates include public health surveillance, contract management,organization management, provider incentives, research solutions,interoperability solutions, creation of research data marts, patientoutreach, and the like.

As mentioned, the condition-specific and/or objective-specific programtemplates may be automatically generated, or may be automaticallygenerated and modified by a user, or may be built entirely by the user.The user in this case, may include a programmer or administrativepersonnel associated with a healthcare organization. This user maycustomize the template so that it more directly reflects thecharacteristics of the organization including any contractual provisionsthat the organization adheres to. For instance, the user may modify orcustomize the template by modifying population qualifiers, referenceranges, measurement thresholds, intervention strategies, algorithms,nomenclature concepts, and the like.

FIG. 5 depicts an exemplary graphical user interface (GUI) 500 of alogic editor that may be used to modify and/or build acondition-specific program template. The GUI 500 includes a clinicalasset library area 510. In this case, the clinical asset library area510 includes clinical assets or concepts associated with the diseasecondition diabetes mellitus. Assets may include diagnoses (includingdiagnostic codes), medications, lab values, and the like. The GUI alsoincludes a template building area 512. In this case, a program templateused to identify patients in a population who have diabetes or are atrisk of developing diabetes is being generated. The GUI further includesa source code area 514 where source code is automatically generated anddisplayed as the program template is being built in the templatebuilding area 512. The source code area 514 is configured to enable auser to make changes directly to the source code; these changes areautomatically reflected in the template building area 512. In oneaspect, the source code is specific to population health management.Additionally, the GUI 500 includes area 516 which, in this case, isinitiated when the user selects “Payer” 513. The area 516 presents alist of payers, and the user is able to select payers that areassociated with the healthcare organization.

Turning back to FIG. 2 and moving on the population management service212, the receiving component 228 is configured to receive patient datafrom one or more sources that may be disparate in nature. Patient data,as used herein, refers to any type of data, including healthcare ormedical care data that is related or relevant to a patient. Patient datamay include, but is not limited to, clinical data, financial data, andactivity data.

Clinical data, as used herein, refers to any healthcare or medical dataparticular to a patient. In embodiments, clinical data is medical careor healthcare data resulting from or associated with a health or medicalservice performed in association with a provider in a healthcareenvironment (e.g., lab test, clinical encounter, ecare, evisit, etc.).Clinical data may include, but is not limited to, a health history of apatient, patient information, patient identifiers, patient demographics(e.g., age, gender, race, etc.), diagnoses, treatments, a familyhistory, genomic history, immunization records, medications, testresults, allergies, adverse reactions, procedures performed, socialhistory, advanced directives, alerts, claims data, vital signinformation, data traditionally captured at the point of care or duringthe care process, a combination thereof, and the like. The clinical datamay be derived from claims data, data supplied by the patient's insurer,electronic medical record data, device data, health information exchange(HIE) data, personal health records (PHRs), continuity-of-care documents(CCD), patient-inputted data (via, for example, a patient portal),provider-inputted data, pharmacy data, and the like.

Financial data refers to any financial information relevant to apatient, such as insurance data, claims data, payer data,patient-provided data, and the like. For example, a patient may inputvia a patient portal financial information such as income, purchasinghabits, credit card information, etc. Activity data refers to data thatmay impact a patient's health but is derived from sources outside of orremote from the patient's healthcare environment. For example, activitydata may comprise data supplied by county health agencies, state healthagencies, communities, research data marts, federal public healthagencies, and the like. Representative types of activity data includedisease statistics or crime statistics associated with a community orgeographic area, socioeconomic characteristics of population segmentslocated in a particular geographic area as indicated by zip code (e.g.,age, income level, education level, race, gender, and the like), supportservices provided by a community such as elder care programs, healtheducation programs, health clinics, church programs, nutrition-assistprograms, exercise programs, and the like.

The data store builder 230 is configured to build, maintain, and/orupdate the population data store 234 using the patient data received bythe receiving component 228. The data store builder 230 receives theincoming raw data in various formats or nomenclature includingproprietary formats. The raw data may include data that is structured,unstructured or semi-structured. A copy of all the raw data received bythe data store builder 230 is stored in its raw form. This enables thepopulation health management system 200 to derive new knowledge usingthe raw data at a later point in time.

For each source of data, the data store builder 230 transforms the rawdata into industry-standard nomenclatures such as Logical ObservationIdentifiers Names and Codes (LOINC), Unified Medical Language System(UMLS), or Systemized Nomenclature of Medicine (SNOMED), and compilesthe data by source into a reference record. Reference records arecleansed, standardized, and machine-readable. The reference recordssupport all industry-standard terminologies, which enables the fidelityof the data sources to be retained. When the raw data is in aproprietary format, the data store builder 230 leverages machinelearning techniques to map codes to industry-standard terminologies.Machine learning techniques recommend appropriate standard terminologycodes thus speeding up the mapping process. The data store builder 230is also configured to apply natural language processing techniques todata contained in clinical notes, reports, and documents. The data storebuilder 230 is configured to reconcile conflicting pieces of data orsynthesize pieces of data that should be viewed together and to learnfrom each data source thereby enabling the mapping and transformationprocessing times to be reduced for new data sources.

As mentioned, the data store builder 230 is configured to track thesource of the data and associate the source with the source's referencerecord. The reference record for a particular data source containsconsent, access, and/or privacy rules associated with the data source. Aparticular reference record may be utilized by multiple differentorganizations. This is especially useful in situations where theorganizations that utilize a particular reference record change overtime. By way of illustrative example, a provider group may provide datato the population health management system 200. The provider group mayinitially be affiliated with a first healthcare organization and grantthe first healthcare organization access rights to the provider group'sreference record. At some later point in time, the provider group maycancel its contract with the first healthcare organization and establisha contract with a second healthcare organization. In this case, insteadof the provider group having to re-send all of its data to the secondhealthcare organization, it can simply grant the second healthcareorganization access rights to its reference record and withdraw accessrights from the first healthcare organization.

The data store builder 230 combines the information contained in thedifferent reference records to form person-centric longitudinal healthrecords known as population records. Each record is longitudinal in thatit contains information on all of the patient's health encounters eventhough the encounters may have occurred at disparate locations and withdisparate providers. Each population record is stored in the populationdata store 234. Thus, the population data store 324 includes multiplepopulation records relevant to a population of patients. The data storebuilder 230 utilizes the matching component 232 to match patients withtheir data and create the person-centric longitudinal populationrecords.

The matching component 232 utilizes one or more probabilistic patientmatching algorithms to match patients to their clinical, financial, andactivity data. Patients may be matched to their data based on forexample, patient name, patient identifiers, and the like. For moregeneral data such as socioeconomic conditions by zip code, a patient maybe matched to an appropriate set of socioeconomic data using, forexample, the patient's zip code. The matching component 232 is alsoconfigured to reconcile all of the patient's records even if the recordsare associated with different patient identifiers. For instance, apharmacy may use a first patient identifier when dispensing medicationsto a patient while a care clinic may use a second patient identifierwhen treating the patient. The matching component 232 is configured toreconcile these patient identifiers and match all of the pertinentmedical information associated with the patient. Each patient's data isalso normalized via grouping codes from multiple terminologies that meanthe same thing thereby reducing redundant data.

Different patient matching algorithms may be utilized by the matchingcomponent 232 to generate different population records suitable fordifferent purposes or use cases. For example, one algorithm may be usedto create a population record that includes identified, detailedclinical information about the patient. This type of population recordis suitable for use by clinical-type programs that need access togranular data about the patient. A different matching algorithm may beused to create a population record that is de-identified (e.g., strippedof patient-identifying data). A de-identified population record maycontain less granular information about the patient and be suitable foruse by research-type programs after obtaining the patient's consent.Other patient-centric population records may be created for, forinstance, analytics purposes.

The population data store 234 may be networked storage or distributedstorage including storage on servers located in the cloud. Thus, it iscontemplated that for some embodiments, the information stored in thepopulation data store 324 is not stored in the same physical location.The information within the population data store 234 may exist in avariety of standardized formats including, for example, narratives andother data.

FIG. 7 depicts the relationship between the raw data, reference records,and population records and is referenced generally by the numeral 700.Raw data sources 710 include such sources as acute care facilities,primary care providers, specialty providers, payers, HIE, pharmacies,patient-inputted information, public health agencies, community sources,and the like. Additional data sources beyond those shown arecontemplated. The raw data sources 710 may contribute data in a varietyof nomenclatures and formats, including proprietary formats. The rawdata received from the raw data sources 710 is stored by source in rawdata stores 712, 714, and 716. The raw data stores 712, 714, and 716 maybe networked storage or distributed storage including storage on serverslocated in the cloud.

At a step 718, the raw data is transformed into industry-standardnomenclatures by, for example, techniques such as cleaning,standardizing, natural language processing, machine learning, and thelike. After transformation at step 718, the transformed data is storedin reference records 720, 722, and 725. Each reference record 720, 722,or 724 stores transformed data from a single data source. The referencerecords 720, 722, and 722 may be networked storage or distributedstorage including storage on servers located in the cloud.

At a step 726, the data from the reference records 720, 722, and 724 iscombined and undergoes a second transformation process before beingstored in patient-centric population records 728, 730, and 732. Thetransformation process at step 726 includes application of probabilisticpatient matching algorithms, normalization, and reconciliation asexplained above. The population records 728, 730, and 732 may benetworked storage or distributed storage including storage on serverslocated in the cloud.

Different programs 734, 736, and 738 can access the population records728, 730, and 732 or sub-portions of the population records 728, 730,and 732. The programs 734, 736, and 738 may be condition-specific suchas decision support, patient registries, care management, predictiverisk, and the like. Likewise, the programs 734, 736, and 738 may beobjective-specific such as public health surveillance, interoperabilitysolutions, attribution, outreach, intelligent learning systems, contractmanagement, provider incentive, physician experience/outcome, networkmanagement, and the like. A particular population record may be accessedby more than one program. Likewise, a particular program may access aplurality of population records.

At a step 740, different end-users are able to utilize the output of theprograms 734, 736, and/or 738 via one or more computer applications.End-users are numerous but representative examples include populationmanagers, primary care physicians, care managers or health coaches,specialists, patients, healthcare organization administrators, payers,and the like.

Turning back to FIG. 2, the compiler 236 is configured to extract one ormore condition-specific or objective-specific program templates from thenetwork management service 210 and use information in the contracts datastore 222, the organization directory data store 224, and the providerdirectory data store 226 to modify or localize the template to aparticular healthcare organization. This may be done in response to theparticular healthcare organization initiating and/or updating apopulation health management program directed to the disease conditionor an objective that is the subject of the program template. Aftermodifying the condition-specific program template using theorganizational data, the compiler 236 outputs one or more softwareagents or programs that may be used by, for example, the program engine214.

The program engine 214 is configured, at run-time, to access patientpopulation data stored in population records in the population datastore 234 and execute the customized condition-specific orobjective-specific programs against one or more of the populationrecords, or sub-portions of the population records to generate patientpopulation data for the healthcare organization.

The program templates may include identification programs 238 thatidentify different types of population segments. For example, populationsegments may be identified based on a condition such as, for example,wellness, diabetes, stroke, hypertension, and the like. Populationsegments may be identified based on affiliation with a particularhealthcare organization or a particular provider. Additionally,population segments may be identified that have a condition and areeligible for different outreach programs. The type of identification isdependent upon the underlying purpose of the program. The identifiedsegment along with associated patient data is stored in a registry 248and is available for use by various applications utilized by thehealthcare organization.

Another program is a prediction program 240 that takes a populationsegment identified by the identification program 238 and stratifiespatients within the segment based on disease type, and/or severity ofthe disease condition, and/or severity of risk for contracting thedisease condition. For example, a diabetes population may be identifiedand then stratified based on whether the patient has Type 1 Diabetesversus Type 2 Diabetes, whether the diabetes is controlled versusuncontrolled, and/or whether the patient(s) is compliant with medicationversus non-compliant. Other stratification schemes may be employed suchas stratifying by cost of care, demographic features, and the like. Thestratification information is stored in a stratification data store 250that is available for use by various applications utilized by thehealthcare organization.

Yet another program is an attribution program 244 that attributespatients to various healthcare providers within a healthcareorganization. Attribution is geared towards pairing a patient with anoptimal set of healthcare providers to effectively manage the patientwhile keeping costs down. As explained above, the attribution programmay be customized to the healthcare organization or may be a standardattribution program. Turning now to FIG. 8, FIG. 8 depicts a flowdiagram of an exemplary method 800 of attributing patients to one ormore healthcare providers associated with the healthcare organization.At a step 810, a program engine, such as the program engine 214 of FIG.2, that is running an attribution program for the healthcareorganization accesses population records (such as the population records728, 730, and 732 of FIG. 7) to identify patients that are presentlyaffiliated with the healthcare organization.

At a step 812, organizational data associated with the healthcareorganization is accessed. The organizational data may be stored inassociation with a data store such as the contracts directory 222, theorganization directory 224, and the provider directory 226 of FIG. 2.The organizational data is searched for “supply” data such as identityand number of providers associated with the organization, currentworkloads associated with the providers, identification of providers byspecialty, location information of the providers including whether theprovider is accessible to people with disabilities, outcomes (e.g.,scores) associated with different providers, and the like.

The organizational data also includes objectives specified in one ormore payer contracts that the healthcare organization has entered into.The objectives specified in the payer contracts may indicate thatproviders meet quality measures for a predefined number of patients(these patients are known as “scorable patients”) before the providerand/or the organization is reimbursed and/or receives incentive feesfrom the payer. If the attribution program is a standard program that iscurrently not customized to the healthcare organization,organization-specific parameters may be accessed. These parametersspecify attribution rules for the healthcare organization. For example,the healthcare organization may have a rule specifying that patientswith low levels of complexity be assigned solely to a primary carephysician, while patients with high levels of complexity be assigned toa primary care physician as well as a specialist.

At a step 814, the program engine again accesses the population recordsof those patients identified as being affiliated with the healthcareorganization to determine, among other things, previous and currentprovider relationships associated with the patients. This is possiblebecause each population record is longitudinal in nature and contains ahistory of all healthcare encounters associated with the patient, evenif the encounters occurred at disparate locations and disparate times.Other examples of patient information that is accessed includegeographic location of the patient, disease conditions, personalpreferences regarding the type of provider the patient wishes to see(e.g., female versus male, board certified, older versus younger,specialist versus primary care, and the like), socioeconomic informationas determined by, for example, the zip code at which the patientresides, demographic information (e.g., gender, age, and the like),financial information as determined by claims data or patient-provideddata, genomic information associated with the patient (e.g., whether thepatient has been identified as having a gene mutation leading to anincreased risk of cancer or disease), and whether the patient isdisabled and requires specialized access to provider offices. Patientdata may also include social information such as the presence of familycare givers, alcohol and tobacco use, church affiliations, use ofsupport services, and the like. Some of this information may be supplieddirectly by the patient through a patient portal while other informationis gleaned from different data sources as explained above.

At a step 816, the program engine attributes each of the patientsassociated with the healthcare organization to one or more providerswithin the healthcare organization based on both the organizational dataand the patient data. The program engine is designed to take intoaccount each piece of organizational data and patient data when definingthe attribution scheme with the result that the attribution scheme isnot only customized to the healthcare organization but is personalizedto the patient. For example, a first healthcare organization may utilizehealth coaches while a second healthcare organization does not. Anattribution scheme for the first healthcare organization would includehealth coaches while an attribution scheme for the second healthcareorganization would not include health coaches.

In one aspect, a tiered attribution scheme may be utilized wherein apatient is first attributed to a certain type of provider based on theorganizational data, and then the actual identity of the provider isdetermined based on patient data. For example, a diabetic patient mayfirst be attributed to a primary care physician and an endocrinologistbased on organization-specific parameters or rules. Patient data is thenused to determine, for example, a primary care physician and anendocrinologist within geographic proximity to the patient and who meetpatient preference factors. The output of the attribution program isstored in association with an attributed relationships data store suchas the attributed relationships data store 254 of FIG. 2. This datastore can also be utilized by various applications.

In one aspect, an existing attribution scheme can be modified byproviders. In this aspect, the provider may be presented with a list ofpatients that have been attributed to him or her. The provider has theoption to accept and/or reject the attribution scheme. If accepted, theattribution scheme is implemented. If the provider chooses to reject theattribution scheme, the provider is given the option of proposing a newattribution scheme. For example, in an intra-office setting, theprovider may suggest that a patient be attributed to another providerwithin the group. Based on the proposal, a segment of the attributionprogram may be re-executed to determine if the proposed change isfeasible based on organizational and patient data. In another aspect, ahealthcare organization is able to run an attribution scenario usingorganizational data to see if the attribution scenario is feasiblebefore actually implementing the attribution scenario.

FIG. 9 depicts another flow diagram of an exemplary method 900 ofupdating an attribution scheme based on the receipt of neworganizational or patient data. At a step 910, population records areaccessed by an attribution program engine to determine patients who arecurrently associated with a healthcare organization. At a step 910,organizational data associated with the healthcare organization isaccessed to determine the number and identity of providers associatedwith the organization, location of the providers, providers byspecialty, outcomes associated with the providers, and the like. Asexplained above, the organizational data may also include objectivesspecified in payer contracts as well as organization-specific rules orparameters regarding attribution.

At a step 914, the population records of those patients who arecurrently affiliated with the healthcare organization are again accessedto determine patient information such as previous providerrelationships, current provider relationships, patient preferences,social history, and the like. At a step 916, each of the patients isattributed to one or more providers based on the organizational data andthe patient data.

At a step 918, updates to one or both of the organizational data and/orthe patient data are received. The types of updates may include anychange to the organizational data and/or the patient data such as theaddition of a new patient to the network, changes in patient or providerlocation, updated patient preferences, change in patient disease statethat may necessitate the addition of another provider to care for thepatient or the deletion of a currently-attributed provider, the additionor deletion of providers associated with the healthcare organization, amodification to a payer contract that changes incentive or reimbursementobjectives, new organization attribution rules, and the like.

In response to the updated organizational and/or patient data, theattribution scheme may be automatically modified at a step 920. Likeabove, the modification is made based on both the organizational dataand the patient data. By way of illustrative example, updatedorganizational data may indicate that a provider has moved his/heroffice location. A patient currently attributed to the provider mayinitially be attributed to another provider that is located closer tothe patient. However, this patient's preferences may indicate that thepatient wishes to maintain the relationship with the current providerregardless of the provider's location. In another case, a patient mayindicate that geographic location of the provider is his/her primaryconcern and, thus, this patient would be attributed to another providerthat is located closer to the patient.

FIG. 10 depicts a flow diagram of an exemplary method 1000 ofattributing scorable patients to a provider. As briefly outlined above,the concept of a “scorable patient” is based on new payer strategies forreimbursing and/or incentivizing providers and healthcare organizationsto provide quality care at a reasonable cost. One strategy that is usedby Medicare is to base reimbursement off of re-admission rates ofpatients who suffer from certain disease conditions such as, forexample, pneumonia. If readmission rates for these patients are keptbelow a contract-specified threshold, reimbursement at full levels isprovided to the organization and/or provider. Many private payers areinstituting fee-sharing or incentive arrangements with healthcareorganizations. These arrangements provide financial incentives tohealthcare organizations and providers if certain quality measures orobjectives are met. For instance, a provider caring for diabeticpatients may receive an incentive if a certain number of his diabeticpatients maintain their hemoglobin A1C levels below a defined threshold.The quality measures and/or objectives associated with scoring areembodied in payer contracts which are part of the organizational dataassociated with the healthcare organization. Those patients who are partof the group of patients for whom quality measures are being monitoredand upon which incentives are based are considered a scorable patientgroup.

With this as a background, and turning to FIG. 10, at a step 1010,patients currently associated with a healthcare organization areidentified by accessing the patient-centric longitudinal populationrecords. At a step 1012, organizational data associated with thehealthcare organization is accessed. Among other things, theorganizational data includes contract objectives specifying qualitymeasures to be met by providers and/or the organization including thenumber of patients that should be in the scorable patient groups.

At a step 1014, population records of those patients currentlyassociated with the healthcare organization are accessed and pertinentpatient data related to attribution is identified. At a step 1016, eachof the patients is attributed to one or more providers based on both theorganizational data and the patient data as outlined above.

At a step 1018, and with respect to at least one of the providers,patients attributed to the provider who are scorable are identified.Again, this may be based on information contained in the populationrecords and on contract data. A patient is identified as scorable if heor she meets the parameters spelled out in the payer contract. Forinstance, a payer contract may specify that a patient is scorable fordiabetes management if the patient is between a certain age range andsuffers from Type 1 diabetes. Patients meeting these criteria who havebeen attributed to the provider are thus identified as scorable.

At a step 1020, a subset of the scorable patients is attributed to theprovider as a scorable patient group. Again, this may be based on termsin the payer contract that specify how many patients should be in ascorable group in order to measure achievement of quality measures.Thus, for example, although a provider may be attributed 1000 patients,only 200 of these may be considered scorable, and of these, only 60 areplaced in the measured scorable group.

Yet another program is a contract and organization management program(not shown in FIG. 2) used by healthcare organizations to managefinancial and clinical objectives between payers, providers, andpatients. As explained above, a healthcare organization's organizationaldata includes contract data, data about the healthcare organization, andprovider data. As contracts are established between the healthcareorganization and payers, or between the healthcare organization and itsproviders, the contracts are digitized and stored in association with,for example, the contracts data store 222. The contracts containcontract objectives defining terms under which reimbursements are madeand/or incentives provided to the healthcare organization and/or itsproviders. Some of these contract objectives include quality measurecontract objectives. Each quality measure contract objective describes aquality measure to be met, the number of patients to be included in thequality measure group (i.e., the scorable patient group), and thepercentage or number of patients in the scorable patient group that arerequired meet the quality measure before an incentive is provided. Forinstance, a quality measure contract objective for a provider associatedwith the healthcare organization may specify that an incentive of adefined amount will be awarded if 60% of a 60 patient scorable groupattributed to provider have hemoglobin A1C levels below a predefinedthreshold. The amount of the incentive may be scaled based on thepercentage met. Quality measure contract objectives defined at theorganization level may provide incentives to the organization if, forexample, a certain percentage of its providers meet quality measurecontract objectives for one or more conditions.

With this as a background, and turning to FIG. 11, a flow diagram isdepicted of an exemplary method 1100 of a healthcare organizationmanaging its contracts using organizational data and patient data storedin population records. At a step 1110, organizational data associatedwith the healthcare organization is accessed from, for example, thecontracts data store 222, the organization directory 224, and theprovider directory 226 of FIG. 2. The organizational data may include,among other things, current and historical provider outcome data,current and historical organization outcome data, current and historicalattribution schemes including current scorable patient groups,department or provider utilization data (e.g., radiology utilization,emergency room utilization, and the like), and the like. Theorganizational data further includes contract data such as contractobjectives associated with quality measures. The contracts may bebetween payers and the healthcare organization, between the organizationand its providers, and/or between payers and providers associated withthe healthcare organization. The quality measure contract objectives maybe set at both the provider level and the organization level. Afterbeing accessed, the organizational data may be further stratified basedon, for example, payer, provider, scorable patient groups, and/orquality measures.

At a step 1112, patient data of patients in the scorable patient groupsis accessed from population records stored in association with, forexample, the population data store 234. The patient data accessedincludes data related to the quality measure contract objectives. Thetype of data accessed is dependent on the nature of the quality measurebut may include lab results, procedure results, diagnoses, indicationsof whether actions have been taken or attempted to be taken, readmissionrates, and the like. After being accessed the patient data may also bestratified based on, for example, scorable patient group, payer,attribution to a particular provider, and the like.

At a step 1114, for each identified scorable patient group, it isdetermined the number of or the percentage of patients in the scorablepatient group who meet the quality measure(s) as specified by thequality measure contract objectives. At a step 1116, a determination ismade for each scorable patient group whether the percentage of patientsin the scorable group that meet the respective quality measure is equalto or greater than the percentage or number set forth in the qualitymeasure contract objective. Additionally, a determination may be made ofthe percentage or number of providers associated with the healthcareorganization whose patients meet the quality measure contractobjectives.

If, at a step 1118, it is determined that the percentage is equal to orgreater than that set forth in the quality measure contract objectives,then an amount of financial incentive is determined. Again, the amountof the incentive is dictated by the contract terms and may be scaledbased on the percentage met. The amount of financial incentive may bedetermined at the provider level and the organization level.

If, however, at a step 1120, it is determined that the percentage isless than that specified in the quality measure contract objectives,then one or more recommendations are automatically generated that willenable the healthcare organization to better meet the contractobjectives. The recommendations may include changing the currentattribution scheme to re-align poor performing patients with providersthat have historically better provider outcomes, changing the currentattribution scheme to address the over- or under-utilization ofproviders or departments (a concept known as venue shifting), makingrecommendations on types of providers that should be hired to betterassist patients in meeting quality measures, and the like. By way ofillustrative example, outcome data may indicate that providers in theorganization's emergency room department are not meeting quality measurecontract objectives because the department is being over utilized. Basedon the type of quality measures not being met, a recommendation may begenerated suggesting that, for example, a health coach and a primarycare physician be hired by the organization. Recommendations may also bemade as to which quality measures need most improvement so that thehealthcare organization may make appropriate changes including, forexample, increasing efforts at patient outreach. Besides generatingrecommendations at step 1120 if contract objectives are not met, thefinancial impact of not meeting those contract objectives may also bedetermined. This may be broken down by provider, provider groups,provider type, payers, type of quality measures, and the like.

Besides the method outlined in FIG. 11, the contract and organizationmanagement program may also utilize organizational and patient data togenerate information relating to the achievement of quality measures.This type of information may include a summary of performance-to-date,projections regarding future performance, high-performing providersversus low-performing providers, high and low performing specialties,high and low performing provider groups, high and low performing qualitymeasures, payer performance, cost effectiveness of providers and/orpayers, and the like. All of the information generated by the contractand organization management program is stored in a data store that isavailable for use by the healthcare organization via one or morecomputer applications.

The information generated by the contract and organization managementprogram may be presented to the organization on one or more userinterfaces (UIs) as shown in FIGS. 12-14. FIG. 12 depicts an exemplaryUI 1200 presenting information generated by the contracts andorganization management program discussed above. The organization isable to view data related to current contract performance. For example,at area 1210, target and actual performance data is presented for thecurrent year. The target and actual performance data 1210 pertains to acontract between the organization and a payer and includes financialdata 1212, performance metric data 1214, and utilization data 1216. Theorganization is also able to view data related to future contractperformance at area 1218. Future contract performance 1218 may be based,in part, on current or historical contract performance. Future contractperformance 1218 includes target and projected financial data 1220,performance metric data 1222, and utilization data 1224. Area 1226 of UI1200 presents the top ten conditions with the greatest expenditures.This helps the organization to visualize what measures need to beimplemented to reduce these costs. Area 1228 provides a breakdown of theorganization's current finances.

FIG. 13 depicts a UI 1300 that provides an overview of current caredistribution and recommendations generated by the contracts andorganization management program. Area 1310 presents a table overview ofutilization by provider type; a bar graph 1312 depicts this sameinformation in graphical form. From table 1310, it can be seen, forexample, that the organization's specialists, emergency department (ED),and nursing home are being utilized at capacity or are over capacity.Area 1314 presents key performance indicators for patients covered by aparticular payer contract and/or for all patients covered under payercontracts. The key performance indicators 1314 are compared to nationalbenchmarks.

Area 1316 presents selectable recommendations automatically generated bythe contract and organization management program. The recommendationsaddress areas of concern as indicated by the organizational and patientdata. In one aspect, the recommendations comprise venue shifting orprovider shifting recommendations where a different care scheme otherthan the existing care scheme is recommended. The venue shifting orprovider shifting recommendations are based on organizational data forthe specific healthcare organization. For example, as shown at numeral1318, the system has made a recommendation that 2% of primary carephysician visits be shifted to eVisit (e.g., contacting a patientelectronically to determine how the patient is doing) based on currentcare distribution information. This recommendation leveragesorganization information indicating that the healthcare organization hascapabilities to implement eVisits. The organization can select whichrecommendations it would like to implement and additional graphicalrepresentations showing the impact of the selected recommendations aregenerated and presented as shown in FIG. 14.

FIG. 14 depicts an exemplary UI 1400 illustrating the effects ofselected recommendations on future performance. UI 1400 includes area1410 that highlights the target projections for the next billing year,original projections, and new projections based on the implementation ofselected recommendations broken down by financial data, performancemetric data, and utilization data. Area 1412 presents a bar graph 1411of utilization by provider type for the current year and a bar graph1413 of projected utilization by provider type for the next billing yearbased on selection of recommendations. Area 1414 is a graph showingfinancial savings related to a particular payer contract based on theimplementation of recommendations, and area 1416 depicts a graph showingfinancial savings related to all of the organization's contracts basedon the implementation of the recommendations. Additionally, area 1418depicts a graphical representation of the difference in income bycontract type between the current year and the next billing year basedon the implementation of the selected recommendations.

Continuing, another program is an outreach program (not shown in FIG. 2)that automatically and without human intervention identifies providersand/or patient population segments eligible for one or more outreachevents and executes the outreach event. An outreach event can be definedas an action or communication by the organization or its providers tocontact providers or patients regarding one or more quality measures.The outreach events may be tied to, for example, quality measurecontract objectives embodied in payer contracts established between ahealthcare organization and one or more payers or embodied in contractsor agreements between the organization and its associated providers. Forinstance, a quality measure contract objective may state that 90% ofwomen over the age of 40 be notified that they should schedule amammogram. Generating and sending a communication to eligible womenwould meet this quality measure contract objective.

Turning to FIG. 15, FIG. 15 depicts a flow diagram of an exemplarymethod 1500 of performing intra-organization outreach.Intra-organization (e.g., within the organization) outreach enables theorganization to automatically identify and contact those providers whoare failing to meet one or more quality measure objectives. At a step1510, organizational data, such as the provider directory 226 of FIG. 2,is accessed to identify providers who are currently not meeting qualitymeasure objectives and the identity of those quality measure objectives.Additional data about the provider may be accessed at this point such aspreferred method of communication. At a step 1512, an outreach event isautomatically generated for those providers identified as not meetingone or more quality measure objectives. The nature of outreach event maybe based on, for example, the provider's preferred method ofcommunication and include a communications such as a printed letter,email, text, call, and the like. The outreach event may includeautomatically generating the content of the letter, email, text, orcall. The content, in turn, informs the provider of what qualitymeasure(s) is not being met, a current percentage of completion, andactions that can be taken by the provider to meet the qualitymeasure(s).

FIG. 16 depicts a flow diagram of a method 1600 of executing outreachevents to patients associated with a healthcare organization or aprovider. At a step 1610, patient-centric longitudinal populationrecords stored in association with, for example, the population datastore 234 of FIG. 2, are accessed to identify patients currentlyassociated with the organization or the provider who are eligible for anoutreach event related to one or more quality measures. A patient iseligible for an outreach event if the patient has not yet met one ormore quality measures as specified by the organization, contracts, orproviders. Once identified, additional patient information is accessedsuch as preferred mode of communication, patient preferences, socialhistory, family support, and the like.

At a step 1612, organizational data is accessed from, for example, theorganization directory 224 and the provider directory 226 of FIG. 2.Organizational data may include current organization workload, currentprovider workload, operating hours, location information, accessibilityinformation, and the like. At a step 1614, the outreach event isautomatically generated based on the patient information and theorganizational data. The outreach event may comprise a communicationsuch as a printed letter, a text message, an email, or a phone call, theselection of which is based, in part, on communication preferencesassociated with the patient. The content associated with thecommunication includes an identification of the quality measure(s) thathas not been met, and information on how to accomplish the qualitymeasure. Information on how to accomplish the quality measure iscustomized based on the organizational data and the patient data. Forinstance, if the outreach event relates to a quality measure such asscheduling an appointment for a test, the organizational data is used todetermine appointment times that are available and that meet expressedpatient preferences.

A record of attempts to contact the patient is maintained. Thisinformation is useful to establish an audit trail that may allow theprovider and/or the organization to be excused from meeting a certainquality measure contract objective. For example, contract terms mayprovide that performance of a quality measure contract objective isexcused or considered met if the provider or organization makes acertain number of attempts to contact the patient. Keeping a record ofattempted patient contact is important for meeting this type of contractterm.

For patients who qualify for multiple outreach events related todifferent quality measures, the method 1600 is adapted to synthesize themultiple different quality measures and generate a single outreach eventor communication related to the multiple different quality measuresusing the organizational data and the patient data. For example, aperson may need to have his or her blood drawn for hemoglobin A1Ctesting as well as receive a mammogram. Organizational data and patientdata is used to generate a single communication that addresses both ofthese quality measures and includes, for example, a single time frameand/or location that enables the patient to accomplish both of thesequality measures and that further meets the patient's preferences.

Returning to FIG. 2, another program is an intervention program 246 thatgenerates stateful workflows to reduce condition-specific risk or toimprove outcomes of patients in the identified segment that have thecondition. As with the output of the other programs, the output of theintervention program 246 is specific to the healthcare organization. Byway of illustrative example, a first healthcare organization may havecontractual provisions with a payer that stipulates that theorganization will be reimbursed for the use of health coaches to monitormedication compliance. A second healthcare organization may havecontractual provisions with a payer that stipulates that theorganization will not be reimbursed for the use of health coaches inmonitoring medication compliance. When generating a workflow to monitormedication compliance amongst diabetic patients, a workflow for thefirst organization would utilize the health coaches to call the patienton a daily basis to make sure the patient is taking the correctmedication. On the other hand, a workflow for the second organizationwould generate, for example, an email that is sent to the patientreminding the patient to take his/her medication. These workflows arestored in an action data store 256 that is available for use by thehealthcare organization.

An additional program may include a measurement program 242 thatmeasures various outcomes associated with the identified populationsegment. Outcomes may include, for example, readmission rates,medication compliance rates, re-infection rates, patient satisfactionresults, compliance with standards-of-care, and the like. The output ofthe measurement program 242 is stored in association with a measuresdata store 252 that is available for use by the healthcare organizationto improve quality control measures, etc. The information may also beutilized by payers to determine rates of reimbursement. For instance, apayer may have incentive reimbursements if readmission rates are keptbelow a predefined threshold. In another example, reimbursement ratesmay be reduced if the patient satisfaction results are poor. Any and allsuch aspects are contemplated as being within the scope of theinvention.

As mentioned the output of the programs 238, 240, 242, 244, and 246 andthe other programs set forth above may be used by a healthcareorganization via one or more computer applications in a variety of ways.Some examples include using the data to initiate alerts, provide accessto patient records, create patient lists or registries, generate summarypages, initiate quality control measures, and the like. Another exampleis a score card application that utilizes a builder program to enablethe organization to build a scoring plan for itself, its providers, itspayers, and/or its patients and present the results of the score plan onone or more score card user interfaces. Execution of the score cardapplication leverages the organizational data, the patient-centriclongitudinal population records, and the output of some or all of theprograms outlined above.

With respect to the builder program for the score card application,FIGS. 17-23 depict exemplary UIs used by a healthcare organization tobuild score plans for itself, its providers, its payers, and/or itspatients. FIG. 17 depicts a start-up page 1700 for defining the scoreplan properties. Input fields are provided that enable a healthcareorganization to enter textual data or to select from one or more optionsassociated with a particular input field. Input field 1710 is adapted toreceive a plan name. Input field 1712 provides options for selecting anentity to score or enroll in the score plan. Options include anorganization, provider group, provider, payer, and/or patient. Inputfield 1714 enables the organization to specify a minimum number ofpatients that should be part of a scoring group for a quality measure inorder for that quality measure to count towards the entity's overallscore. Selection of input field 1716 credits the entity for the qualitymeasure even though there is not the minimum number of patients in thescoring group. Input fields 1718 and 1720 enable the organization tospecify a scoring period for the entity by indicating start and enddates for the scoring period. Because data, such as claims data, maystill be received and processed after the designated end date, inputfields 1722 and 1724 enable the organization to specify a lockdown startdate and a processing end date.

Turning to FIG. 18, FIG. 18 depicts an exemplary UI 1800 that enablesthe organization to set up categories and associate quality measureswith those categories. A category can be entered into input field 1810.Categories represent logical groupings of quality measures. The category1810 may be selected from a set of predefined categories ororganization-specific categories. A list of organization-specific orstandardized quality measures is presented in area 1812. The qualitymeasures 1812 may be customized based on the category 1810. Each of thequality measures 1812 includes an “Add” option by which it can beassociated with the category 1810. For instance, the organization couldselect quality measures 1814 and 1816 and associate them with thecategory 1810.

FIG. 19 depicts an exemplary UI 1900 presented after a selection of thequality measures 1814 and 1816 on UI 1800. UI 1900 includes the category1810 as well as the added measures 1814 and 1816. The quality measures1812 continue to be presented so that the organization is able toassociate additional quality measures with the category 1810.

FIG. 20 depicts an exemplary UI 2000 that enables the organization todesignate targets for each of the selected quality measures. FIG. 20includes the category 1810. Additionally, the UI 2000 includes a qualitymeasure 2012 (e.g., HbA1C<7% which is a measure of wellness indiabetics). The area under the quality measure 2012 has been expanded sothat the organization can select providers, payers, organizations,and/or patients to score. For instance, the organization can selectproviders or provider groups to score in area 2014, and an organizationto score in area 2016 for the quality measure 2012. With respect to theproviders 2014, the organization has elected to set targets for thequality measure 2012 for all providers at field 2018 (by selecting froma list of options) and also specifically for endocrinologists at inputfield 2024 (by selecting from a list of options). For all the providers2018, the organization selects a mathematical operator at input field2020. Mathematical operators includes such things as greater than, lessthan, equal to, greater than or equal to, less than or equal to, and thelike. At input field 2022, the organization selects a target percentage.Thus, for all the providers 2018, the organization has specified thatthe providers 2018 meet the quality measure of keeping HbA1C levels lessthan 7% if 70% of the scorable patient group meets this quality measure.For the endocrinologists 2024, the organization has elected to lower thetarget 2028 to 30% because this specialty may treat more uncontrolledcases of diabetes and it would be unlikely for this group to have 70% ofthe patients in the scorable patient group meet the quality measure.

With respect to the organization 2016, options are provided for scoringthe organization by providers or patients at area 2030. Like withproviders 2014, operators and targets can be selected or inputted. Thus,as shown in FIG. 20, if “providers” is selected at area 2030, theorganization 2016 would meet the quality measure if 30% of the providersmet the goal of keeping HbA1C levels less than 7% for their diabeticpatients. If “patients” is selected at area 2030, then the organization2016 would meet the quality measure if, for example, 30% of the scorablepatient group at the organization have HbA1C levels less than 7%.

FIG. 21 depicts an exemplary UI 2100 presented after information hasbeen inputted/selected on UI 2000. The UI 2100 includes many of the sameelements as the UI 2000 but additionally includes, for example, “points”input boxes 2122 and 2126, and “calculated percent of total score” 2124and 2128. The points input boxes 2122 and 2126 enable an organization toassign a number of points to, in this case, providers 2018 andendocrinologists 2024 if the designated quality measure is met. Theamount of points accumulated by a provider at the end of a scoringperiod generally affects incentive amounts and/or reimbursement amounts.After the points are entered in, for example, the input box 2122 for theproviders 2018, a calculated percent of total score is presented at2124. This feature enables the organization to understand the impact ofan assigned score on the provider's total score and to adjustaccordingly. For instance, the endocrinologists 2024 will likely bescored on fewer items than the providers 2018. Thus, assigning, forexample, 2 points to the endocrinologists 2024 at box 2126 maysignificantly impact the percent of total score 2128 for theendocrinologists 2024 (i.e., it may be 20% of the endocrinologists'score compared to 2% of the providers' score). UI 2100 also includes a“weight” box 2130 associated with the category 1810. The weight box 2130enables the organization to weight categories.

FIG. 22 depicts an exemplary UI 2200 after points have been entered andthe percent of total score has been calculated. As shown, 2 points havebeen entered in box 2122 for the providers 2018, which is 2% of theirtotal score as shown at 2124. By contrast, the two points entered in box2226 for the endocrinologists 2024 is 20% of their total score as shownat 2128. The organization may reconsider how many points to score thequality measure 2012 for the endocrinologists 2024 based on this.

FIG. 23 depicts an exemplary UI 2300 presenting a summary page of theinformation inputted on the previous builder screens. The UI 2300includes a sorting area 2310 by which the organization can sort byorganization, provider group, provider, and/or patient for each qualitymeasure. The outcome of the sorting is shown at 2312. The score planbuilder may also include a UI that presents all of the score planscurrently being drafted and/or used by the healthcare organization. Auser could select one of the plans to view the plan and/or edit theplan.

Once the score plan has been built and implemented, the results arepresented on score card UIs. The score card UIs may be configured topresent outcome data that is relevant to a provider, a provider group,and/or the organization as a whole. One example of a provider score cardis depicted in FIG. 24. FIG. 24 illustrates an exemplary provider scorecard UI 2400 that presents information related to a particularprovider's progress towards achieving a maximum number of total pointsas determined by the score plan builder for that particular provider. Asmentioned, the total score and/or percentage completion towards thetotal score may be used to determine reimbursements and/or incentivesfor the provider. The UI 2400 includes the provider name 2410 and a bargraph 2412 graphically illustrating the provider's progress towardsreaching his maximum number of points. As seen at 2414, the provider2410 is 42% of the way to achieving his maximum number of points orscore. A total number of patients attributed to the provider 2410 isshown at 2418, and the number of patients in scorable patient groupsattributed to the provider is shown at 2416. Area 2420 depicts a treemapof all of the quality measures against which the provider 2410 is beingscored. A treemap displays hierarchical information in a series ofclustered rectangles, which together represent a whole. The size of eachbox represents a quantity (either proportionately or inversely). Therectangles may be colored differently and have different colorintensities to indicate the relative degree of importance of aparticular rectangle in comparison to the other rectangles in thetreemap. Information may be directly displayed in the rectangles, theinformation may be revealed upon interaction with the rectangles, or acombination of both.

The UI 2400 depicts the top five quality measures 2422, 2424, 2426,2428, and 2430 for which the provider 2410 is demonstrating the leastprogress towards completion, thus enabling the provider 2420 to quicklyassess areas for improvement. The quality measures 2422, 2424, 2426,2428, and 2430 are presented in the largest rectangles to help draw theuser's attention. For instance, with respect to the quality measure 2422“Diabetes Care,” the provider 2410 is 0% of the way towards achievingthe total score for this quality measure 2422. Additional informationmay be presented upon hovering over the various rectangles. Forinstance, the number of patients in the scorable patient group for theparticular quality measure may be presented, along with the number ofpatients in the scorable patient group who have achieved the particularquality measure. The determination of which top five quality measures topresent on the UI 2400 is determined by the system. The system may baseits determination of the top five quality measures 2422, 2424, 2426,2428, and 2430 based on not only the percent progress towardscompletion, but also the number of patients in the scorable group, theimpact of achievement of the quality measure on the provider's overalltotal score with the least amount of effort, and the like.

FIG. 25 depicts another exemplary provider score card UI 2500 thatpresents scoring information in the form of opportunity indexes. Theconcept of an opportunity index is useful when a provider is at thebeginning of his/her scoring period. At the beginning of the scoringperiod, a provider will naturally not have achieved any completiontowards meeting his or her scoring goal. Thus, it is not particularlyuseful to present the top five quality measures that need improvement.Instead, the system determines quality measures that may be difficultfor the provider to achieve—these are known as opportunity index qualitymeasures. One example of a quality measure that may be difficult for aprovider to achieve is threshold-based measures where a particularquality measure is required to be maintained within a certain range. Forinstance, the quality measure of keeping hemoglobin A1C levels less than7% for diabetic patients not only requires that the diabetic patientcome in for blood draws, but also requires medication and dietsupervision on the part of the provider and the patient. Other types ofquality measures that may fall within the opportunity index type includequality measures that were missed by the provider in the previousscoring period and/or new measures that the provider has never beenscored against. Compare these types of quality measures to a qualitymeasure requiring a provider to contact a patient to schedule amammogram. This type of quality measure requires little effort on thepart of the provider and may be easily obtainable.

The UI 2500 contains some of the same elements as the UI 2400 and likenumbering is used to label these elements. The UI 2500 includes atreemap 2520 displaying all of the quality measures against which theprovider 2410 is being scored. Instead of percentage of completioninformation being presented however, opportunity index information ispresented in association with the quality measures. The information inthe UI 2500 is useful at the beginning of the provider's scoring periodand enables the provider 2410 to quickly see what areas offer the mostopportunity to improve the provider's overall score. The top fiveopportunity index quality measures as determined by the system are shownin as 2522, 2524, 2526, 2528, and 2530. The quality measures 2522, 2524,2526, 2528, and 2530 are presented in the largest rectangles to draw theuser's attention. Using the quality measure “Pediatric Wellness” 2522 asan example, the provider 2410 has an opportunity to improve his overallscore by 0.6% if he meets this quality measure. The provider scorecardUI 2500 may dynamically shift to the provider scorecard UI 2400 as thescoring year progresses allowing the provider to see where he or she canimprove with the least amount of effort.

Score cards can also be generated at a provider group level and/ororganization level. FIG. 26 depicts an exemplary provider groupscorecard UI 2600 that may be used by an organization to see how aparticular provider group is performing with respect to one or morequality measures against which the group is being scored. This may beuseful to the organization, for example, when determining whether torenew the provider group contract.

The UI 2600 includes the provider group name 2610 as well as a bar graph2612 that illustrates the percentage towards completion of the totalnumber of scorable points for the provider group 2610. For example, theprovider group 2610 is 42% towards completion of the total number ofscorable points (indicated by element 2614). The UI 2600 also indicatesthe total number of patients 2618 attributed to the group 2610 and thetotal number of patients in scorable patient groups 2616 attributed tothe group 2610.

A treemap 2620 is presented that includes all of the quality measuresagainst which the provider group 2610 is being scored. Like the UI 2500,the top five opportunity index quality measures 2622, 2624, 2626, 2628,and 2630 are presented along with opportunity index percentages. Thetreemap 2620 may be presented at the beginning of the provider group'sscorable year and dynamically transition to a treemap similar to the UI2400 that displays percentage toward completion data as the scoring yearprogresses. The UI 2600 also includes a graph 2632 displaying trendinginformation regarding the completion of quality measures by the providergroup.

Although not shown, it is contemplated that score cards could begenerated that display quality measure information about individualpatients. This may be useful when a patient attributed to a providersuffers from multiple medical conditions that place him or her intomultiple quality measure scorable patient groups. Patients of this typemay have a large impact on the provider's total score, and the providerwould be interested in knowing what quality measures associated with thepatient may be most difficult to meet (e.g., at the beginning of theprovider's scoring year), and/or which of the patient's quality measurescould be improved with the least amount of effort by the provider (e.g.,later in the provider's scorable year). Information on the patient'squality measures could be presented in the form of a treemap as shown inUIs 2400, 2500, and 2600.

In one aspect, a healthcare organization can run the programs outlinedabove in a demonstration mode and generate a projected set of data foranalysis. FIG. 6 is an exemplary graphical user interface demonstratingin a graphical form the output of the various programs 238, 240, 242,244, and 246 with respect to a population segment that has diabetesmellitus type 2. Area 610 provides a breakdown of the identifiedpopulation segment, and area 612 provides a breakdown in costsassociated with care according to different facilities and/or divisionswithin the healthcare organization. Area 614 graphically presents abreakdown in provider assignment or attribution. As can be seen, theprogram projected that health coaches 615 will consume 138% of providerassignments. Based on this information, the healthcare organization canmodify the program template (using, for example, the template buildingarea 512 of FIG. 5). Thus, instead of actually implementing thepopulation health management program and noting its problems, ahealthcare organization can view the projected problems beforehand andimplement the needed modifications to the templates.

The population health management system 200 is an closed-loop systemmeaning that as a healthcare organization utilizes the output of theprograms outlined above, more organizational and patient data isgenerated which is fed back into the system 200 and used to update thevarious data stores. Further, the system 200 operates over and iscompatible with existing electronic medical record systems associatedwith healthcare organizations, even if these electronic medical recordsystems are disparate in nature. Thus, a healthcare organization canutilize the system to manage population health without having to incursignificant financial costs to reconfigure its already-existingelectronic medical record system.

Turning now to FIG. 3, an exemplary flow diagram is depicted of a method300 of enabling a healthcare organization to manage population health.At a step 310, a condition-specific program template is extracted from,for example, a network management service such as the network managementservice 210 of FIG. 2. The extraction of the condition-specific programtemplate may be accomplished by a compiler such as the compiler 236 ofFIG. 2. The condition-specific program template may have beenautomatically generated by the network management service, manuallycreated by, for example, a programmer associated with a healthcareorganization, or automatically created and modified by a user. In oneaspect, the condition-specific program template is constructed using apopulation-health specific programming language. The program templatesare configured to identify population segments that have a particularcondition or are at risk for developing the condition, and stratifypatients within the population segment based on, for example, degree ofseverity or risk, financial factors, demographic factors, and the like.The condition-specific program templates are also configured toattribute patients within the segment to healthcare providers, generateworkflows designed to improve outcomes and/or reduce risk, and measureintervention outcomes.

Once the condition-specific program template is extracted at the step310, it is customized or localized to a particular healthcareorganization at a step 312. Customization includes taking into accountthe organizational data associated with the healthcare organization.This data may be stored in data stores such as the contracts data store222, the organization directory data store 224, and the providerdirectory data store 226 of FIG. 2. The organizational data may includehealthcare facilities associated with the healthcare organization,healthcare providers associated with the healthcare organization, andcontractual provisions between the healthcare organization and itsassociated payers. At a more granular level, organizational dataincludes provider names, credentials, geographic location of providersand healthcare facilities, operating hours, capabilities, clinical andfinancial objectives associated with the contracts, and the like. At astep 314, the customized program template is communicated to a programengine such as the program engine 214 of FIG. 2.

FIG. 4 depicts a flow diagram of an exemplary method 400 of managingpopulation health and may be seen as a continuation of the method 300.At a step 410, the program engine receives the customizedcondition-specific program templates from the compiler. And, at a step412, the program engine receives patient data from, for example, apopulation management service such as the population management service212 of FIG. 2. Patient data includes diagnoses, demographic information,insurance or payer information, location information, preferenceinformation, and clinical data such as lab results, X-rays, procedureresults, clinical notes, and the like.

At a step 414, the program engine executes the customizedcondition-specific program templates against the patient data. Theoutput of the program engine comprises population health data that canbe used by the healthcare organization to manage the health of apopulation segment. For instance, the program engine may generate a listof patients associated with the healthcare organization who aresuffering from a disease condition. The patients may be stratified bydisease severity, and the patients may be attributed to one or moreproviders associated with the healthcare organization who canefficiently manage the disease condition. Workflows may be generated toimprove outcome and efficiently utilize the attributed healthcareproviders. Intervention outcomes are measured; these outcomes may beused by payers to determine an amount of reimbursement to the healthcareorganization.

The present invention has been described in relation to particularembodiments, which are intended in all respects to be illustrativerather than restrictive. Further, the present invention is not limitedto these embodiments, but variations and modifications may be madewithout departing from the scope of the present invention.

What is claimed is:
 1. A system for organizational management of patientpopulation health, the system comprising: a computing device associatedwith a population health management service having one or moreprocessors and one or more computer-storage media; and one or more datastores coupled with the population health management service, whereinthe population health management service: receives a plurality of setsof organizational data associated with one or more healthcareorganizations; stores the plurality of sets of organizational data inassociation with the one or more data stores; receives raw dataassociated with a population of patients from one or more raw datasources; transforms the raw data into one or more standard medicalnomenclatures; and generates a plurality of population records using thetransformed data, wherein each of the plurality of population recordscomprises a longitudinal record of a particular patient's data.
 2. Thesystem of claim 1, wherein the one or more healthcare organizations aredisparate.
 3. The system of claim 1, wherein the plurality of sets oforganizational data comprises at least data about the one or morehealthcare organizations including at least operating hours, type ofcare provided, and geographic location.
 4. The system of claim 1,wherein the plurality of sets of organizational data comprises at leastdata about one or more providers associated with at least one of the oneor more healthcare organizations including at least provider names,areas of provider practice, and geographic location of providers.
 5. Thesystem of claim 1, wherein the plurality of sets of organizational datacomprises at least data about one or more contracts between the one ormore healthcare organizations and respective payers associated with theone or more healthcare organizations including at least quality measurecontract objectives contained in the one or more contracts.
 6. Thesystem of claim 5, wherein the at least quality measure contractobjectives comprise clinical quality measures against which a healthcareorganization or a provider is scored.
 7. The system of claim 1, whereinthe one or more raw data sources from which the raw data associated withthe population of patients is received are disparate raw data sources.8. The system of claim 7, wherein the raw data associated with thepopulation of patients is received in different formats ornomenclatures.
 9. The system of claim 1, wherein the one or more rawdata sources from which the raw data associated with the population ofpatients is received comprise at least clinical data sources, financialdata sources, and federal and state data sources.
 10. A computerizedmethod carried out by a population health management service having atleast one processor for creating patient-centric longitudinal populationrecords, the method comprising: receiving from a plurality of raw datasources raw data associated with a population of patients; for each rawdata source of the plurality of raw data sources, transforming, usingthe at least one processor, the each raw data source's raw data intostandard medical nomenclature and compiling the transformed data into areference record; for each patient in the population of patients,extracting the each patient's data from a set of reference records; andfor the each patient in the population of patients, generating alongitudinal record of the each patient's data.
 11. The computerizedmethod of claim 10, wherein subsequent to receiving the raw dataassociated with the population of patients from the plurality of rawdata sources, storing a copy of the raw data.
 12. The computerizedmethod of claim 10, wherein the raw data is transformed into standardmedical nomenclature using at least machine learning techniques andnatural language processing.
 13. The computerized method of claim 10,wherein the standard medical nomenclature comprises at least one ofLogical Observation Identifiers Names and Codes (LOINC), Unified MedicalLanguage System (UMLS), or Systemized Nomenclature of Medicine (SNOMED).14. The computerized method of claim 10, wherein each reference recordincludes consent, access, and privacy rules associated with the eachreference record's raw data source.
 15. The computerized method of claim10, wherein the longitudinal record of the each patient's data isgenerated using one or more probabilistic patient matching algorithms.16. The computerized method of claim 10, wherein the longitudinal recordof the each patient's data is identified.
 17. The computerized method ofclaim 10, wherein the longitudinal record of the each patient's data isde-identified.
 18. One or more non-transitory computer-readable mediahaving computer-executable instructions embodied thereon that, whenexecuted, perform a method of enabling one or more healthcareorganizations to manage health of one or more patient populationsegments, the method comprising: receiving a plurality of sets oforganizational data associated with the one or more healthcareorganizations, the plurality of sets of organizational data comprisingcontract data, provider data, and healthcare organization-specific data;storing the plurality of sets of organizational data in one or more datastores; receiving from a plurality of raw data sources raw dataassociated with a population of patients; for each raw data source ofthe plurality of raw data sources, transforming the each raw datasource's raw data into standard medical nomenclature and compiling thetransformed data into a reference record; for each patient in thepopulation of patients, extracting the each patient's data from a set ofreference records; and for the each patient in the population ofpatients, generating a longitudinal population record of the eachpatient's data; and executing at least one of a diseasecondition-specific program or objective-specific program against atleast a portion of the plurality of sets of organizational data storedin association with the one or more data stores and longitudinalpopulation records of at least a portion of the population of patientsto generate one or more results used by at least one of the one or morehealthcare organizations to manage the health of a patient populationsegment.
 19. The media of claim 18, wherein the at least one diseasecondition-specific program or the objective-specific program iscustomized to the at least one of the one or more healthcareorganizations based on parameters specified by the at least one of theone or more healthcare organizations.
 20. The media of claim 19, whereinthe at least one disease condition-specific program or theobjective-specific program is customized by personnel associated withthe at least one of the one or more healthcare organizations using alogic editor.